InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0007.txt

Text File | 1993-07-02 | 6.3 KB | 124 lines

Terry Gray writes:
> If delivery is to a pool of centrally-managed servers, why does the user
> need to worry about forwarding?  Or is this to accommodate folks with
> departmental hosts?

Partly. Also users doing spells at other places for the odd 6 months.

> I agree that ph should be evaluated before falling into the X. hole
> (though Michigan claims that X.500 over the new light-weight stack is
> working well for them), but my question is: why is this an IMAP issue?

Because IMAP2 _could_ be a way (because it's extensible, and because it
already does one major component pretty well, i.e. mail retrieval) to
provide advanced mail functions over IP to clients which don't have a full
OSI stack. I think the difficulties of X.500 are being exaggerated (and
many are fixed in X.500(92)). For example, some sites have _already_
converted their finger daemons to do X.500 lookup. This also provides some
X.500 functionality to IP-based clients. However, there is no standard for
X.500-over-finger, and it is not integrated with mail.

> I would have guessed it was an MUA function.

Not sure what you mean here. The MUA isn't going to have an OSI stack
(if it was, we'd use P7 rather than IMAP2). So it would have to agree on
a private X.500-over-IP protocol to talk to a relay that could do the
DUA functions for it. There is no existing standard protocol (unless this
Michigan thing is going to become one). If the new protocol has to fit in
somewhere, IMAP2 seems as good a place as any, as there are benefits from
integrating DUA with MUA, e.g. reverse lookup on addresses in received
messages, and use of the Directory to store configuration information.
From [e-mail]  Wed Sep  2 22:53:01 1992
Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA02056; Wed, 2 Sep 92 22:53:01 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA16882; Wed, 2 Sep 92 22:50:33 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA16876; Wed, 2 Sep 92 22:50:27 -0700
Date: Wed, 2 Sep 1992 22:33:50 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Subject: re: IMAP2 futures?
To: A Grant <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 01 Sep 92 22:16:45 BST, A Grant wrote:
> why not return percentage of quota used so far

The question is, what does that mean to the user?  Telling me that I am using
45% of my quota tells me nothing about the question of whether or not copying
this 50,000 character will will blow me away or not.  Note too that other than
remote COPY, there is very little that can be done in IMAP to *use* more
quota.  You can reduce your usage via IMAP, but I question whether telling
someone `you are using 95% of your quota' is going to do anything to encourage
him to use less.  Remember, that statement can be interpreted to mean `you are
only using 95% of what you are entitled to.'

I think this needs more consideration and input from other individuals.  I'm
not sure if this is an IMAP issue or not.

> > Modern-day c-client does detect and clean up properly when quota problems
> > hit.
> Er, how? Do you mean the c-client in the Washington distribution has
> agreed a private protocol (e.g. a text in a BAD message) to pass this
> information on?

The /usr/spool/mail operations that could make the mail file larger are
checked for a worst case expansion vs. quota and are rejected if it would run
out of disk space.  If a quota problem hits with COPY, the COPY is completely
backed out of and the entire COPY command is rejected with a NO.  Remember,
the server does not run with privileges and so has to obey the kernel on
quotas.

> I mean sending on a mail message at the server (i.e. in a mailbox) without
> having it delivered to the client and then sent back via SMTP. Apart from
> being more efficient, if the user gets a MIME message that breaks their
> client (e.g. by being humungously large), server-end forwarding might be
> the only means of passing the message on to the system administrator.
> Ideally it should accept an attached note, and encapsulate the original
> mail using MIME. But then you're half way to a 'send mail' function.

Most of us consider `mail forwarding' to mean encapsulating the message within
another message.  You would be putting user interface and sending within a
message.  `Remailing' in this fashion may be reasonable though.

However, this is merely `for efficiency' since the same resulting function can
be accomplished by existing mechanisms.  This is a good reason to reject it;
any function which by its fundamental nature is optional and exists only for
`efficiency' tends not to get implemented widely.  You can either end up with
a lot of protocol baggage or recognize reality.  Most modern protocol design
does the latter.

> I guess 'draft message handling' would be more accurate. I wouldn't
> particularly mind if a client had to extract draft messages out of the
> IMAP2 server and then post them off using SMTP. What I am trying to get
> out of is a situation where a user is tied to one system because all
> their drafts are stored there. Our users want to treat mail like a
> telephone network - walk up to the nearest PC or Mac and there you are,
> complete with draft messages, user preferences etc.

Remote storage of mail drafts is an interesting suggestion and it is certainly
something to bring up to the IETF-REMMAIL group.  I would support an effort on
this, but I don't think it belongs in IMAP under the `avoid too much baggage
in IMAP' banner.

Also, I'm not convinced drafts belong on the IMAP server as opposed to the
`home directory' server.  What if the IMAP server is overseas (this is a real
world situation for me!)?  Putting it in IMAP seems to be false `efficiency'.


I think you have some really good ideas, just that you're seeking the wrong
place to see them implemented.  The stuff you suggest belongs in a distributed
mail system just as IMAP does, but it does not (necessarily) belong in IMAP.
Please consider bringing it up to the IETF-REMMAIL group.

Regards,

-- Mark --